
-------- TML Message #880 --------

Archive-Message-Number: 880
Date: Tue, 30 Jan 90 15:52:47 EST
From: ("William B. Morrison") morrison@pyr.gatech.edu
Subject: Star System Digest Volume 2 Issue 1


Date: Thu, 25 Jan 90 13:07:18
From: Bill Morrison (Coordinator) <morrison@pyr.gatech.edu>
Reply-To: Traveller System Generation Group@pyr.gatech.edu
Subject: Traveller System Generation Group Digest V1 #1
To: traveller@dadla.wr.tek.com


Traveller System Generation Thu, 25 Jan 90    Volume 2: Issue:1

Today's Topics:

                       Bad news, and worse news...
                             DESIGN_SPEC
                            Galactic scale
                           Member's address
                           Mail from Joshua
                       Traveller Computer Programs
                           TRAV Sys Gen Digest


***************************************************************************
** STAR SYSTEM DIGEST: star system generation, storage, and display.     **
** All followups on this topic should be sent to morrison@pyr.gatech.edu **
** They will be edited for clarity and resent to the Traveller Mailing.  **
***************************************************************************

***************************************************************************
** Administrivia: Well a new year has started and I'm already late       **
**                the next edition of the digest out. This issue contains**
**                the BUILD 1 design specification of our system         **
**                generation program -- our thanks to those who directly **
**                and indirectly put in all of the hard work.            **
**                                                                       **
**                Since we've been having some problems with the group's **
**                internal mail distribution, I'll be sending out a      **
**                revised mail alias supplied by James Perkins. This     **
**                alias is the one he uses from the TML distribution so  **
**                it is guarenteed to be more correct than the one I     **
**                created.                                               **
**                                                                       **
**                I also want to thank Dan Corrin for all the work he    **
**                put in on compiling the survey results.                **
**                                                                       **
**                The message "Galactic scale" was previously posted     **
**                to the TML, but is relevant to the generation of star  **
**                maps. Since it was posted to the TML, it is re-posted  **
**                without the explicit permission of the poster.         **
**                                                                       **
**                The message "Mail from Joshua" contains some random    **
**                number and probability table look-up routines. More    **
**                detailed information on the table handling routines    **
**                can be found in the addendum message to this volume.   **
**                                                                       **
**                The V02N01 addendum (a seperate mail message) contains **
**                information on a hex mapping algorithm, the results of **
**                the questionaire, and information on table handling    **
**                routines.                                              **
**                                                                       **
**                Lastly, the machine I'm on still maintains its         **
**                connection to the world, but it is on a day-by-day     **
**                basis. So, I may not be able to continue as group      **
**                coordinator much longer. I'll get onr weeks warning so **
**                I'll let the TML and the star systems group know as    **
**                soon as I do. If the next project I'm on has its       **
**                machine on the Internet, I'll be glad to continue.     **
**                                                                       **
**                                       -- Bill Morrison                **
***************************************************************************

- --------------------------------------------------------------------------------

Date: Tue, 12 Dec 89 08:48:28 EST
From: morrison@pyr.gatech.edu (William B. Morrison)
Subject: Re: Bad news, and worse news...

Actually, I'm glad to see people volunteering in the event that I cannot
continue as moderator. Since everyone is mentioning scripts for doing
things, I have a copy of the "digestify" program used by various
newsgroups (sun-spots, uunet groups, etc) to automatically create digests
from articles saved in a mailbox. Since I'm not (read can't) use the alias
mail feature at our site to automatically reflect mail, it's the only
automation I really need.

BTW, I still have no further info on to what connectivity I'll have
come Jan 1, but I'll keep you all posted.

- --Bill

- --------------------------------------------------------------------

Date: Tue Dec  5 14:35:30 1989
From: richard@agora.hf.intel.com (Richard Johnson)
To: morrison@agora.hf.intel.com
Subject: DESIGN_SPEC

Well, I guess I'll fire an opening salvo.  Here's a proposal for
"build one", version 0.0

THIS IS REALLY LONG!!!!! ("Danger, Will Robinson...")

I am primarily going to talk about the interface, and user
considerations (that's my job, and I don't what I'll do to
the real designers with this..)  As much as possible, I have
tried to interpret the results of Dan's questionnaire and use
them here.

- -----------------General Considerations--------------------------

1.  Build one produces subsector maps, solar system maps, or
    sector maps, in Megatraveller format.

    Build two is another program that adds more mapping capability.

    Build three etc. add more functionality, compatability and data
    base usage of the star system files generated.
 
 
2.  The primary output is postscript; letter-sized paper.
 
3.  Secondary output is an ASCII file that can be used for data
    manipulation (data-base type search/sort, etc.) as well as for
    mapping.
 
4.  The computer terminal is used to control the program, not as
    an output device (except for preview).
 
5.  Program control (terminal stuff again) should be to VT-type
    terminals ("stdio" ?).  This gives the greatest compatability,
    and allows dial-in users.
 
- ------------------Output Map Considerations--------------------------

Subsector Maps------------------------------------
 
The "standard" sized (see MT ref'smanual, page 20) hex map
of a subsector (8 X 10 hexes) has the following characteristics:
 
    It is half a page.
        We will use a whole (8.5 X 11- inch) page (just to
        start an argument).
 
        Because we will generate more detailed world information, and
        because we will use the computer to search and sort through
        this more detailed data for us, we don't need to have a summary
        of the sector's worlds right next to the map.
 
        If we print the map "landscape" (sideways on the page -
        "Portrait" is printing on a page with the narrow side of the
        paper at the top), then we have half a page for notes and
        information that is more textual than visual.  Conversely, I
        have used full-page maps, with larger hexes and prefer them
        even though it means the world information is elsewhere.  (Of
        course, all of the more useful, more detailed world information
        is elsewhere anyway.)  Probably we should use of the page for
        map; we'll need room for a key and some of the more imiportant
        notes.
 
    It has numbered hexes; I'm not sure we need to to this.
 
    Hexes are shown.  We should show hexes.
 
    It has the name of each world at the bottom of that world's hex.
    We should do this also.
 
        We can play with type sizes and faces (this is PostScript)
        till we find one suitable.  When you photocopy small letters,
        a medium sans-serif face, like Helvetica, copies the best.
 
    It has the starport type identified.  We should, too.

        This is a single bold-face letter.  I suspect some worlds may
        have more than one starport.  Do we put simply the best one up?
        Do we somehow indicate > 1 class A starports?

    Types of military establishments are shown.  We should show these
    too.
 
        This is done by hollow or filled icons, a star for a navy base
        (I suspect we could use a hollow star for a local navy base, a
        filled one for "Imperial" navy (whatever that is now.), a
        triangle for scout bases and stations, and a square for naval
        depots.  I believe judicial selection of a typeface will give
        us these as characters, so we don't have to "draw" them on the
        map.

    Type of primary world is indicated.  We should show stars, instead.
        (another argument?)

        Hollow or filled circles, or other appropriate images, are used
        for the world, to indicate it's type.  I think, from our
        discussions and from the responses, we'd rather see some indi-
        cation of the star in that location, and whether it is single
        or multiple.  If you're like me, you color in these circles by
        hand to indicate the color of the star; it makes a very pretty
        map.


In general, for subsector maps, we should do pretty much what has gone
before, only use up a whole page for the map.  The actual file structure
we choose to do this, you experienced programmers can decide; just try
to pick one that we use later for other things (like data base queries).

Sector Maps-----------------------------------------------

For Sector maps, the official method is to have subsectors named
by a single letter.  The naming is alphabetic (A,B,C,...P) and in
the same order as the way we normally read.  I don't know which way
is "up" though; I THINK it's spinward.
 
Sector maps should have less detail.  They should show only the
following information:
 
        Class A starports
        A-to-A trade lanes
        MAJOR X-boat routes
        Major military bases
        Subsector Capitols
        significant political boundaries
 
Sector maps should also be on a full sheet of 8.5 X 11 inch paper, but
should not have the hexes drawn on it (it would get cluttered).
 
 
Solar System Maps--------------------------------------------------

I think we should save the output side of this until later.  There
should be a lot of detail that we need to consider with respect to
later builds and functionality.  (i.e. I didn't do this yet)


Other Maps---------------------------------------------------------

See above...

- ------------------------Interface Considerations---------------------------

Most of the general thoughts about the interface, I listed in the
overall design thoughts.  We should try to steer clear of hardware
dependency on initial builds.  (I think we could maybe do this
modularly so that the machine-specific interfaces could be "hung
on" later - any thoughts?)  Thus we should:

        Limit output to ASCII, printable characters (and the space)
        Use line oriented graphics (e.g. 24 lines, 80 columns)
        Use only one color (well, one bit plane)

With this in mind, I propose we lay out the screen something like the
following example: (I hope you've got 80 columns)

- --------------------------------------------------------------------------------
|                                                          |                   | 
|          60 columns X 11 ? lines                         |  20 columns X     | 
|          for text output, messages, etc.                 |  12 lines for     | 
|                                                          |  sample maps      | 
|                                                          |  and titles       | 
|                                                          |                   | 
|                                                          |                   | 
|                                                          |                   | 
|                                                          |                   | 
|                                                          |                   | 
|                                                          -----map title-------
|                                                          |                   | 
|                                                          |  20 columns       | 
|                                                          |  X 12 rows for    |
|                                                          |  Menus            | 
- ----------------------------a line-------------------------|                   | 
|                                                          |                   | 
|           60 columns by 8 ? lines for I/O                |                   | 
|           and keyboard entry operrations                 |                   | 
|           (command line etc.)                            |                   | 
|                                                          |                   | 
- -----------------------------i think I counted about right----------------
 
 
I envision one line of the screen indicating what command is being
used, and a second that tells the user exactly what to do next
(i.e. "Create Base - Select and World and then make a menu selection.")
 
The map area should be continuously updated while the user is
interacting with the program.  When in mapping mode, the user can
select worlds from it (can we do this?), and when n DB mode, it can
highlight the world being edited.
 
The user of the program will need to be able to issue the
following commands:  (feel free to add some if you see the need)

Project Commands:
        Create DB file (=city, world, solar system, subsector, sector)
        Create map file (from DB file or random)
        Delete file
        Rename file
        Edit map file
        Edit DB file
        Save file
        Print file
 
Edit Map Commands:  (notice that these WILL alter the DB file, too)
        Select (move cursor (somehow) to desired spot on map display)
        Unselect (escape?)
        Make X-boat Route (select end points, or many points...)
        Make Trade Route (ibid)
        Make Political/Military Boundary
        Edit World (select world --> enter DB file)
                   (indicate that mode is changing)
        Add Base/Starport (submenu when star selected?)
                Navy
                Scout
                Depot
                Starport
        Delete Base
        Delete Starport
        Delete World
        Delete Trade Route
        Delete X-boat Route
        Delete Political/Military Boundary
        Enter Edit DB File Mode
        Exit to Main Menu level
        Save file
        
                 
Edit DB File Commands:
        Open file
        Save file
        Move up one level (I think the DB is logically heirarchical?)
        Move down one level
        Add a record
        Delete a record
        Modify a record
        Scan records
        Enter Map Edit mode
        Exit to Main menu level
        Save file
        Save record
 


As you can see, there are three basic modes of operation.  The program
comes up in the Main mode, which offers commands to directly operate
the program.

The second mode is primarily for "touching up" maps; for making sure
that routes and boundaries are correct, etc.

I picture the Edit DB file command set being intitally in a "scan
records" mode.  In this mode, a list of records available at that level
is displayed, and the user selects the one to play with.

- ---------------------------Command Descriptions------------------------

Project Commands:

These are available when the program first comes up.  This is the
Main Menu level.

Set Path default        Establishes a pathname prefix to attach to
                        all file names.  For example, setting a
                        path default of "/usr/rdj/trav/" (we might
                        have to watch out on this when converting
                        to other systems) will cause the program
                        to look in this directory for all files and
                        to write files here, too.  equivalent to
                        the UNIX "cd" or the VMS "set def" command.

                        Parms:  pathname


Create DB file          I'm not sure if this should be a DB "file" or
                        a DB "record".  The structrue seems logically
                        Heirarchical (city -> world -> solar system ->
                        subsector -> sector).
 
                        This is ALWAYS randomly generated.

                        Parms:  MT-rules || SpaceOpera || other
                                densly || sparsely populated
                                black holes on || off
                                nebulae on || off
                                TL limits (user-supplied)
                                other?

                        When we get this defined, we'll have a way to
                        transfer universes around.


Create map file         The map needs to use the information in a DB file
                        to get itself drawn.  This is the file that is
                        converted to the chosen output style by the
                        "print map" command and sent to the output device.

                        This file needs to still be in an editable form
                        so that mode two will work.

                        Parms:  DB-filename


Delete file             Removes a specified file from the user's disk.

                        Parms:  filename


Rename file             Changes the name or location of a specified
                        user file.  Origin and destination names are
                        required.  Rename should work with entire DB
                        files, but not with individual records.

                        Parms:  source_filename
                                dest_filename


Edit map file           Changes the program to mode 2, for editing
                        an already created map file.

                        Parms:  filename

Edit DB file            Changes the program to mode 3, for editing
                        an already created data base file.

                        Parms:  filename


Save file               Saves whichever file is open under the same
                        name (and path) in which it was opened.

                        Parms:  none


Print DB file           Copies a specified data base file to a specified
                        output device, in ascii format.  (use a filter
                        to TROFF it, if you want).

                        Parms:  filename
                                printer_id || terminal_id


Print map file          Copies a specified map file to a specified output
                        device, in a specified format.
 
                        Parms:  filename
                                printer_id || terminal_id
                                ascii || PostScript || other


Edit Map Commands:  {Mode 2}
(notice that these WILL NOT also alter the DB file)

Set Path default        Establishes a pathname prefix to attach to
                        all file names.  For example, setting a
                        path default of "/usr/rdj/trav/" (we might
                        have to watch out on this when converting
                        to other systems) will cause the program
                        to look in this directory for all files and
                        to write files here, too.  equivalent to
                        the UNIX "cd" or the VMS "set def" command.

                        Parms:  pathname

Open a map file         Opens a file from the default directory with
                        a (.map?) suffix.  Displays a list of available
                        files.  The user scrolls up and down this list
                        until the proper file is highlighted, then
                        presses <return>.
 
                        Parms: filename indicated by highlighted line
 
 
Select                  Move the cursor (somehow) to the desired spot
                        on the map display and indicate (somehow) that
                        you're there.
 
                        Output: When selected, bolds or flashes the
                                indicated location on the map preview.
 
                        Parms:  cursor location
                                all selected locations (?)
 
Unselect                Move the cursor (somehow) to the desired spot
                        on the map display and indicate (somehow) that
                        you're there.
 
                        Output: When unselected, returns location of
                                the map preview to normal text.
 
                        Parms:  cursor location
                                all selected locations (?)
 
 
Make X-boat Route       User selects a series of points and (somehow)
                        indicates that the route is done or continues
                        off the map.
 
                        Parms:  cursor location
                                selected locations
 
 
Make Trade Route (ibid) User selects a series of points and (somehow)
                        indicates that the route is done or continues
                        off the map.
 
                        Output: none to screen- sets flags as appropriate
                                within the program to create the right
                                output on paper.
 
                        Parms:  cursor location
                                selected locations
 
 
Make Political/         User selects a series of points and (somehow)
Military Boundary       indicates that the route is done or continues
                        off the map.
 
                        Output: none to screen- sets flags as appropriate
                                within the program to create the right
                                output on paper.
 
                        Parms:  cursor location
                                selected locations
 
 
Edit World              Changes the program to mode 3 and brings up the
                        DB editor on the appropriate file and record for
                        the indicated world.  The user selects a world in
                        the normal way.
 
                        Output: Changes program to mode 3
                                tells program which file and record to
                                edit tells user the mode is changing
 
                        Parms:  cursor location
 
 
Delete Trade Route
Delete X-boat Route
Delete Political/Military Boundary
 
                        These three all work the same.  The user selects
                        a series of points and (somehow) indicates that
                        the route is done or continues off the map.
 
                        Output: none to screen- sets flags as appropriate
                                within the program to create the right
                                output on paper.
 
                        Parms:  cursor location
                                selected locations
 
 
Enter Edit DB Mode      Changes the program to mode 3.  Brings up the DB
                        editor with the DB file of the same name as the
                        map file being worked on.
 
                        Output: Changes program to mode 3
                                tells program which file to edit
                                tells user the mode is changing
                                saves map file being worked on as
                                        "fubar.tmp?"
 
                        Parms:  name of file being worked on
 
 
Exit to Main level      Changes the program to mode one.
 
                        Output: changes program mode
                        tells user the mode is changing
 
                        Parms:  none
 
 
Save file               writes the active file to the default directory
                        with the same name in which it was opened.
 
                        Parms:  none

Edit DB File Commands:  {Mode 3}
(I think this is build 2 or three stuff, and I don't have it
well defined yet.  RDJ)

Set Path default        Establishes a pathname prefix to attach to
                        all file names.  For example, setting a
                        path default of "/usr/rdj/trav/" (we might
                        have to watch out on this when converting
                        to other systems) will cause the program
                        to look in this directory for all files and
                        to write files here, too.  equivalent to
                        the UNIX "cd" or the VMS "set def" command.
 
                        Parms:  pathname

 
Open a DB file          Opens a DB file from the default directory with
                        a (.DB?) suffix.  Displays a list of available
                        files.  The user scrolls up and down this list
                        until the proper file is highlighted, then
                        presses <return>.

                        Output: Once the file is open, the top-level
                        records within that file are displayed.
 
                        Parms: filename indicated by highlighted line
 
 
Save file               Writes the active file to the default directory
                        using the same name with which it was opened.
 
                        Parms:  none
 
 
Move up one level       (I think the DB is logically heirarchical?)
                        Moves the selector display up one level of the
                        DB heirarchy - i.e. if the user has just closed
                        a world file, he can "move up" to subsector level
                        to see more worlds to conquer.
 
                        Parms/output - unknown
 
         
Move down one level     See above
 
 
Add a record            Creates a new record for the DB
 
 
Delete a record         Removes a DB record and re-aligns the pointers
 
 
Modify a record         Wow! finally some real editing!
                        Maybe we should require the use of a text editor?
 
 
Scan records            This is the "normal" mode.  It displays the names
                        of records in the text output field.
 
 
Enter Map Edit mode     Changes to mode 2.
 
 
Exit to Main level      Changes to mode 1

Save file               Writes the open file to the default directory.
 
Close record            saves the changes made in the DB record.
 
- --------------------------------------------------------------------
 
In case you hadn't noticed by now, I'm still out to lunch about
the record and data base editing capability of the program.  I'd
like some feedback here.
 
 
It would be nice to name the program, too.
 
Later
        Richard Johnson

- -------------------------------------------------------------------- 

Date: Thu, 14 Dec 89 10:11:45 PDT
From: Richard The Writer <oresoft.uu.net!richard@relay.cs.net>
To: Traveller Mailing List <traveller@dadla.wr.tek.com>
Subject: Galactic scale

I found this in sci.physics and thought it would be of *enormous*
interest, especially to those who are contemplating maps...
        Richard

- --------------------------------
>Subject: Relative distances and sizes in the Universe.

    Several weeks ago I posted a request for slide sets comparing the
relative distances in the solar system and the other stars:  It would
seem that slide sets of this scale system are rather hard to come by.
I sent out a request to several other computer networks, along with
calling a number of planetariums, museum stores, and searched through
various scientific catalogues, all without significant result.

    I was able to use my resources and gather some information
from several friends on various types of relative celestial scales,
and have come up with some relevant information.

    The first selection depicts the solar system on a major league
baseball field from E. C. Slipher's "Planet" section of THE WORLD BOOK
ENCYCLOPEDIA P, VOLUME 15, Field Enterprises Educational Corporation,
Chicago, Illinois, 1964.  If the Sun were the size of a United States
half-dollar (fifty cents) on home plate, the planet Mercury would be
120 centimeters (four feet) away, Venus would be 225 centimeters
(7.5 feet) away, Earth would be 315 centimeters (10.5 feet) distant,
Mars would be 480 centimeters (sixteen feet) away, Jupiter would be
1,650 centimeters (55 feet) from the Sun (at the pitcher's mound),
Saturn would be 3,030 centimeters (101 feet) away (near second base,
and the last planet in the infield), Uranus would be 6,075 centimeters
(202.5 feet) away, Neptune would be 9,540 centimeters (318 feet) away,
and Pluto would be 12,615 centimeters (420.5 feet) distant from the
Sun, deep in the outfield.
 
    To compare planetary diameters, if the Sun were the size of an
average beachball, then Jupiter would be a golf ball, Saturn a Ping-
Pong ball, Uranus and Neptune marbles, Mercury and Pluto pinheads,
and Venus, Earth, and Mars would be about half the size of tackheads.

    The next comparison scale comes from the "Life on Other Worlds"
section of Carl Sagan's PLANETS, LIFE Science Library, 1966.  This
one depicts the solar system on a map of Europe and Africa, with the
average distance between the Sun and Earth, 150 million kilometers
(93 million miles) - also known as one Astronomical Unit (A.U.) -
now equaling 240 kilometers (150 miles).  If the Sun were situated
in Norway, Saturn would orbit just south of Italy, and Pluto would
be 10,400 kilometers (6,500 miles) away along the Cape of Good Hope
in South Africa.
 
    The next source on various celestial scales comes from THE
STARFLIGHT HANDBOOK: A PIONEER'S GUIDE TO INTERSTELLAR TRAVEL, by
Eugene F. Mallove and Gregory L. Matloff (John Wiley & Sons, Inc., New
York, 1989, ISBN 0-471-61912-4, hardcover), which gives the following
description on page 5:  If the Sun were the size of a one-centimeter
(0.4-inch) marble, then Earth would be 0.1 millimeters (0.004 inches)
in diameter and one meter (39.37 inches) from the Sun.  The planet
Pluto would orbit 42 meters (139 feet) from the Sun, and Proxima
Centauri - the Sun's nearest stellar neighbor - would be 292
kilometers (175 miles) away.
 
    The next two books listed are both authored by Neil McAleer.
The first is THE COSMIC MIND-BOGGLING BOOK (Warner Books, Inc.,
New York, 1982, ISBN 0-446-37932-8, paperback).  On the front cover
of the book, the following comparison is made (one of my favorites,
from an aesthetic point of view):  If the solar system out to the
orbit of Pluto could fit in a coffee cup, the Milky Way Galaxy
would be the size of the North American continent.
 
    On page xiii - If you had a specially-designed automobile
which could handle the rigors of spaceflight, it would take you
201 billion years to "drive" from the Sun to the center of the
Milky Way Galaxy at 161 kilometers per hour (100 miles per hour).
Also, if the solar system were 2.54 centimeters (one inch) across,
the Milky Way Galaxy would be 161,000 kilometers (100,000 miles) wide.
 
    On pages 3-4 - If the Sun were the size of a sixty-centimeter
(two-foot) beachball, Earth would be the size of a pea and 6,450
centimeters (215 feet) away.  The planet Jupiter would be a large
orange 31,680 centimeters (1,056 feet) distant from the Sun.

    On pages 12-13 - If the Sun were a 14-centimeter (5-inch) orange,
Earth would be a sesame seed fifteen meters (49 feet) away.  Pluto
would be the size of a grain of millet six hundred meters (3,400
feet) away, and the star Alpha Centauri would be four thousand
kilometers (2,500 miles) from the Sun.
 
    On page 83 - If you could fly a specially modified Boeing 747
jetliner through space at 965 kilometers per hour (six hundred miles
per hour), it would take you 1,903 years to fly from the orbit of
the planet Uranus out to the orbit of Neptune.
 
    On page 128 - If the Sun were a basketball in New York City,
then Alpha Centauri would be another basketball eight thousand
kilometers (five thousand miles) away in Honolulu, Hawaii.
 
    On page 129 - If you traveled at the speed which the APOLLO
spacecraft used in an average six-day round-trip journey to Earth's
Moon (approximately 40,000 kilometers per hour/25,000 miles per hour),
it would take you 850,000 years to reach Alpha Centauri.  By contrast,
the faster PIONEER 10 and 11 and VOYAGER 1 and 2 Jovian probes will
reach that distance (4.3 light years) in only eighty thousand years.
 
    On page 161 - If you used a starship traveling at one-tenth the
speed of light (300,000 kilometers per second/186,000 miles per second)
to reach the farthest star in the Milky Way Galaxy, the ship would
take 800,000 years to reach it from the Sun.  If one Astronomical
Unit (A.U.) - the distance between the Sun and Earth, which is
roughly 150 million kilometers/93 million miles - were reduced to
2.54 centimeters (one inch), then that farthest star would be
127,000 kilometers (79,000 miles) away.
 
    The next selection is from the other Neil McAleer book, THE
MIND-BOGGLING UNIVERSE (Doubleday & Co. Inc., Garden City, New
York, 1987, ISBN 0-385-23039-7, paperback):
 
    On pages 10-11 - If the solar system out to Pluto were 2.54
centimeters (one inch) in diameter, then the center of the Milky
Way Galaxy would be 609 kilometers (379 miles) away.  Also, to
walk one A.U. at five kilometers per hour (three miles per hour)
would take 3,500 years.  To drive one light year at 88 kilometers
per hour (55 miles per hour) would take 12.2 million years.

    On page 15 - The Milky Way Galaxy's longest spiral arm of gas,
dust, and stars is 125,000 light years long.  It would take an
automobile driving at 88 kilometers per hour (55 miles per hour)
1.5 trillion years to cover that distance.
 
    On page 35 - An automobile driving at 88 kph (55 mph) would
take 52 million years to reach Proxima Centauri from the Sun.
 
    The next selection comes from THE UNIVERSE...AND BEYOND by
Terence Dickinson (Camden House Publishing, Ltd., Camden East,
Ontario, Canada, 1986, ISBN 0-920656-48-X, paperback):
 
    On pages 16-19 - If the actual distance between the Milky Way
Galaxy and the Andromeda Galaxy (two million light years) were shrunk
to a typical book-reading distance, then the most remote galaxies
known would be 1.6 kilometers (one mile) away.
 
    If the Sun were shrunk to the size of a 2.54-centimeter (one
inch) Ping-Pong ball, Earth would become a dust speck 240 centimeters
(eight feet) away, with the Moon being an even smaller speck just
6.25 millimeters (0.25-inch) from Earth.  Jupiter would be a pea
1,200 centimeters (forty feet) from the Sun, and Pluto is a dust
speck nine thousand centimeters (three hundred feet) away.  The
Oort Cloud of comets surrounding our solar system would be the
size of atomic particles and reside several kilometers distant,
with the comets themselves averaging several meters apart from
each other.  The Alpha Centauri trinary star system would consist
of two walnuts (Alpha and Beta) and a pea (Proxima) 640 kilometers
(four hundred miles) from our solar system.

    If Earth's solar orbit were reduced to the size of a United
States dime, the average distance between stars is now a little
over one kilometer (1.6 miles).  The Milky Way Galaxy would be
the actual size of Earth.  The distance to the Andromeda Galaxy
would be over half the actual distance between Earth and the Moon.
 
    If you could hold the Milky Way Galaxy in your hand, the stars
in it would be sub-atomic in size, and the Andromeda Galaxy would
be 210 centimeters (seven feet) away.
 
    My final textbook selection comes from CYCLES OF FIRE, by
William K. Hartmann and Ron Miller (Workman Publishing, New York,
1987, ISBN 0-89480-502-9, paperback):
 
    On pages 14-15 - If Earth were the diameter of a microparticle
of soot, then the Sun would be one hundred times larger, the size
of a mote of dust, or one hundredth of a millimeter across.  The
solar system would be the size of a saucer, and the Oort Cloud of
comets would exist several house lots away.  Alpha Centauri would
be another dust mote one to two city blocks from the Sun, and the
Milky Way Galaxy would be the size of North America.  Some of the
other nearby galaxies would be the varying sizes and distances of
Earth's continents.  The known limits of the Universe would stretch
halfway across the solar system.
 
    My friend and co-worker Drew LePage came up with some various
calculations on the celestial distance scale:
 
    If the orbit of Pluto were the size of a U.S. dime, this would be
the size of various distances in the Universe:
 
    Earth's orbit would have a diameter of about 0.5 millimeter (about
half the thickness of a dime).
 
    One light year would be about 15.2 meters (49.9 feet).

    One parsec (3.26 light years) would be about 49.7 meters (163 feet).
 
    The closest star would be 65.4 meters (214 feet) away.
 
    The closest one hundred known stars would be inside a sphere about
    640 meters (2,100 feet) across.
 
    The Sun would be 456 kilometers (283 miles) from the center of the
    Milky Way Galaxy.
 
    The Milky Way Galaxy would be 1,520 kilometers (945 miles) across.
 
    To put intergalatic distances into perspective, if the Milky Way
    Galaxy were the size of a dime:
 
    The orbit of Pluto would be about the size of a hydrogen atom.
 
    The Andromeda Galaxy would be 41.8 centimeters (16.5 inches) away.
 
    One megaparsec would equal 61.9 centimeters (2.03 feet).
 
    The recently discovered "Wall" of Galaxies would be about 40 meters
    (125 feet) to 60 meters (190 feet) away, about 3 meters (10 feet)
    thick, and extend for at least 100 meters (300 feet).
 
    The most distant quasar known would be about 2.6 kilometers
    (1.7 miles) away.
 
    The size of the observable Universe would be about 5.7 kilometers
    (3.5 miles) across.
 
    If nothing else, these figures should give some idea as to just
     how incredibly vast the known Universe is.
 
    Larry Klaes  klaes@wrksys.dec.com

- -------------------------------------------------------------------------

Date: 01 Dec 89 07:37:33 PST (Fri)
From: James T Perkins <jamesp@dadla.wr.tek.com>
Subject: Mail from Joshua

- ------- Forwarded Message
- - ---- begin posting ----

I currently have a library of table handling and random number
generation routines out in beta test.  If you want to be a beta tester,
or just want to see the documentation, please email me.  I've listed
some of the features below.  I can also send a more detailed design to
people who want to give me feed back on it.

random numbers
   Takes strings representing dice rolls ("2d10", "1d8+1", etc.) and
   returns the number.  Also can generate random cards from a deck.
   Has logging/playback facility.  Untested facility to return floating
   point numbers between 0 and 1.
 
table routines
   Can read in, use, and print out tables.  Currently supports two
   types of tables, but is designed to be extendable to to other types.
   Tables are stored in a human readable format (and can be created with
   any text editor).
 
Joshua Levy                          joshua@atherton.com
                        {decwrl|sun|hpda}!athertn!joshua
                        home:(415)968-3718     work:(408)734-9822
 
- ------- End of Forwarded Message

James

- -----------------------------------------------------------------------------

Date: Fri, 29 Dec 89 13:53:11 -0500
From: uunet.uu.net!att!ihlpf!zonker@relay.cs.net
To: att!tektronix!dadla.WR.TEK.COM!traveller@uunet.uu.net
Subject: Re: Traveller Computer Programs

I doubt if anyone at GDW even knows what shareware is much less
understands the concept.  There are no computer jocks (at least that I
know of) with the company.  Almost all their software comes out of house.
Oh they write a few small programs for their PCs, but that is the extent
of it.  The office PCs are used for standard business programming (mainly
text processing). A few of them may even have a PC at home.  GDW as an
business is not currently on any computer network (although I am told
that one of the staff is privately).

If approached correctly you should have no problem, but shareware is not
a concept that is easy for non computer programming types to understand.
You have to stress that this is a simple playing aid that anyone could
write for themselves and all you are doing is saving them the trouble.
You should minimize the profit side of it, but not hide the fact that you
are asking money.  They have been pretty liberal in the past about giving
permission to zerox out of print games, etc..

At any rate, I'll be seeing Frank and Loren next week and if a get a
chance to talk to him and I remember (note we will be quite busy with
other things so this is very doubtful) I'll try to bring up the subject.

                                        Non Cuniculus Est,
                                            Tom Harris

- -------------------------------------------------------------------------

Date: Mon, 20 Nov 89 11:06:44 EST
From: Dave Allen <davea@vlsi.ll.mit.edu>
To: morrison@vlsi.ll.mit.edu
Subject: TRAV Sys Gen Digest

Bill,
I have subscribed to the Trav mailing list for a while and have enjoyed
the System Generation Digest.  I would like you to add me to the
discussion group.  This is a broadcast mailing list, right?  That is,
there is some email address, and if I mail something there it goes to
everybody on the list.  Boy, will I be embarrassed if THIS is the
broadcast address.

I was one of the people who started the Universal Simulation Mailing
List; I recently posted to rec.games.programmer the source to a
continental drift simulator I wrote.  It generates planet maps that
look very realistic.  Although I have been reading planetary science
journals for six years or so, it's just a hobby.

Although I missed the Survey deadline, let me give you a few comments.
I strongly believe ASCII is the right format, so that I can use a text
editor to fix up or create input to one of the programs in the toolset.
I am not interested in MegaTraveller format specifically; I think the
programs should generate _more_ information than MT needs.  Perhaps
there could be an output filter which would take output from the
toolset and print it out on a MT-standard form, if there is such a
beast.

Hope to hear from you soon.
Dave Allen: internet davea@vlsi.ll.mit.edu

- -----------------------------------------------------------------

End of Traveller System Generation Group Digest
******************************

All opinions and material above is the responsibility of the originator.
Submissions: traveller@dadla.wr.tek.com, or uunet!dadla.wr.tek.com!traveller
Administrator: traveller-request@dadla.wr.tek.com (James Perkins)
The TML is made possible by facilities provided by Tektronix, Inc.

-------- TML Message #881 --------

Archive-Message-Number: 881
Date: Tue, 30 Jan 90 23:10 EST
From: METLAY@vms.cis.pitt.edu
Subject: *whimper*












...am i the only person who never got his email game character confirmed?









miserable and alone,

metlay

(PS. sorry for the bandwidth, richard, but if you can't reach steve owens
then there's no guarantee that you can reach me; we're on the same machine)



All opinions and material above is the responsibility of the originator.
Submissions: traveller@dadla.wr.tek.com, or uunet!dadla.wr.tek.com!traveller
Administrator: traveller-request@dadla.wr.tek.com (James Perkins)
The TML is made possible by facilities provided by Tektronix, Inc.

-------- End of TML Messages --------

